Large enterprise application solutions typically use database management systems (DBMS) such as IMS, DB2®, Informix®, Oracle®, MS SQL Server®, and others to store and retrieve data. These database management systems are found in every aspect of the society ranging from business sectors to government institutions. Because of the wide ranging applications, the schemas for these solutions are frequently very complex, including tens of thousands of segments/tables and indexes or more. Concomitantly, the number of objects in these database management systems generally pose significant challenges to typical database administration (DBA) operations such as backup, reorganization, statistics collection, and database space growth management.
Large database and transaction management systems are often designed to share databases or message queues across multiple computer systems. These systems are also referred to as datasharing systems and the members of these systems are referred to as subsystems.
Datasharing systems allow parallel processing and workload sharing for many functions among the subsystems. More importantly, datasharing systems provide many other significant advantages over single (or central) systems including easier scaling to add capacity, lower cost through complete utilization of existing resources, and continuous availability of data and application transactions.
In another aspect, because of the mission critical nature of enterprise database systems, unscheduled application outage or unavailability should always be avoided. With the parallel processing feature of the hierarchical database systems, the concern with database outage is virtually eliminated, as when one of the sub systems is down for any reason, the remaining subsystems will continue to provide database and transaction services.
Therefore, in order to ensure a complete data reliability, these large database systems must be frequently maintained by a skilled staff of database administrators who are responsible for managing and maintaining the datasharing subsystems.
Typically, the database administrators perform database administration operations at subsystem levels, whereby individual sub systems are maintained by the system administrators. These administration operations are generally comprised of tasks such as such as imaging or backup, reorganization, statistics collection, and database space growth management. However, as the complexity in the enterprise database systems grows, the subsystem administration becomes inefficient and costly due to an accompanied increase in the database administration staffing requirement. Furthermore, because datasharing subsystems are individually maintained, they are not completely identical. Thus, as time goes on, the differences in the systems may magnify and the tasks of database administration may become more difficult to manage.
Thus, to address the need to increase efficiency and reduce manpower cost of database management, a single point of control (SPOC) concept is introduced. This concept enables subsystem level operations through a single point of control, whereby administration operations can be performed on multiple sub systems using a single command execution.
Typically, in a single point of control network, a database administrator may select the entire datasharing system or a subset of subsystems for administration operations. Using a database administration application, the database administrator sends an instruction or a system command to the single point of control. Upon execution, the single point of control returns the results of the instruction to the database administrator.
An administrator can send a command to list the resources in the data sharing system. The result is a response from each subsystem with its list of resources. For example, the results may list resources that identify transactions and their associated attributes that are maintained on a datasharing subsystem. When all the queried datasharing subsystems return their results, the information is assembled in a table and presented to the database administrator. With this information, the database administrator examines for exception states that may exist therein.
In a datasharing system, resources must be defined in the same way on each subsystem to ensure that each subsystem will process application work in the same way. By definition then, an exception state is a condition whereby a difference exists in an object attribute of a resource. An exception state may indicate that the resource is not working correctly and not supporting applications properly. This might eventually result in application unavailability or in a corruption of data that will require the database administrator to perform further database administration operations such as backup, reorganization, statistics collection, and addition of database objects. This exception-based approach to database management is commonly employed in the database administration.
Thus, detecting exception states in a database is central to the successful database management. Because large enterprise database systems are typically comprised of several hundreds or thousands of database objects, exception state identification becomes very difficult and labor-intensive. To implement this task, database administrators must analyze the database using their own database administration tools, products provided by the database management system, or utilities available from third-party vendors. These tools collect and report the indicators that help identify objects in the exception state.
As an example of the conventional database administration tools used for detecting exception states in a database, reference is made to FIG. 1, which illustrates a table of information 20 returned from the execution of an instruction command by the single point of control. Table 20 of the conventional database administration tools is comprised of two main features that define a database system (or system group) 100 shown in FIG. 2: resources 30 and attributes 35.
Each resource 30 is comprised of a transaction 40 and a member 45. The transaction 40 represents a name or identification of a database object that maintains a pointer to the data structure. The member 45 is a designated identification for each datasharing subsystem, i.e., 111, 112, 115 as part of the database system 100 (FIG. 2).
Associated with each resource 30 are a set of attributes 35, which can be, for example, further comprised of a local class 55, a segment size 60, and a status attribute 65. These individual attributes may be defined in any manner deemed suitable and meaningful to a database administrator.
Since it is a goal of the database administrator to know if an exception state exists in a resource definition among all the selected datasharing subsystems, upon issuing a query for exception state detection using the conventional database administration tool, the single point of control returns the information in Table 20 as illustrated in FIG. 1. This information is usually arranged in an alphabetical order of the member 45, which identifies the corresponding datasharing subsystem 111, 112, 115. Thus, the transaction 40 and the associated attributes 35 are grouped according to the member 45. As an example, referring to FIG. 1, the transaction 40, labeled as “TRAN1” is displayed in various non-contiguous rows of Table 20 such as in rows 1, 7, 13, and 19 corresponding to the members 45 labeled as “IMS1,” “IMS2,” “IMS3,” “IMS4,” respectively.
In order to identify an exception state from the information above, the database administrator must perform a two-dimensional search of table 20. The first search is performed row by row to locate the transaction 40, and the second search is performed column by column to identify differences in the object attributes 35 associated with the transaction 40. For example, a two-dimensional search first in rows 1, 7, 13, and 19, and then columns 3, 4, and 5 returns an exception state in the local class 55 from the member 45 labeled as “IMS3.”
Normally, this two-dimensional search is performed manually by the database administrator to identify exception states. Because large enterprise database systems can be comprised of hundreds of thousand of resources 30 and attributes 35, spreading across a large number of remotely networked datasharing subsystems, this conventional database administration method therefore bears a significant disadvantage for large enterprise database administration because of its inefficiency and time-consuming labor required to perform manual two-dimensional searches.
Thus, there still remains an unsatisfied need for an improved method for large enterprise database administration. Preferably, the improved method should eliminate the need for a manual two-dimensional search in the exception state identification. Moreover, the improved method should greatly facilitate the exception state detection by providing an enhanced visual method of displaying resources and attributes. These desirable attributes of the improved method for large enterprise database administration should achieve the goal of increased efficiency, which would lead to a reduced cost of database administration operations.